home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / opstat / opstat-minutes-92jul.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  200 lines

  1. Editor's Note:  Minutes received 7/21  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5. Reported by Bernhard Stockman/SUNET
  6.  
  7. Minutes of the Operational Statistics Working Group (OPSTAT)
  8.  
  9. Agenda
  10.  
  11.  
  12.    o Administrative Items
  13.    o Review Internet Draft, is it ready to progress to RFC?
  14.    o Development of tools
  15.    o Review Charter, Goals, and Milestones
  16.  
  17.  
  18. Review of Comments Received About Internet Draft
  19.  
  20. Several comments were made by various Working Group participants.  Jon
  21. Boone (PSC) wants stop-time and filename in a header section so that it
  22. isn't necessary to scan the entire file to find the ending time of the
  23. data.  Agreement was reached to change the time_section to label_
  24. section as follows:
  25.  
  26.  
  27.  
  28.      label_section ::= ``BEGIN_LABEL'' <FS>
  29.      <start_time> <FS>
  30.      <stop_time> <FS>
  31.      <data_file> <FS>
  32.      ``END_LABEL'' <FS>
  33.  
  34.  
  35.  
  36. There was a question about file setup...  is there a need for one big
  37. file or lots of little files?  Should there be multiple sections within
  38. a file?  Matt (PSC) noted that important information was not mentioned
  39. and could be potentially confusing.  They wanted to use very large files
  40. because of their tape storage facilities.  Agreement was reached to add
  41. a sentence saying the specifics of how files are physically arranged is
  42. outside the scope of the document.
  43.  
  44. There was some confusion about the use of tags and variables in the
  45. poll-data section.  Are there multiple tags for different sets of
  46. variables?  It was noted that the draft is vague on time aggregation in
  47. this context and there was no clear way to do it.  There is a need to
  48. provide a representation for, say, the average for 1 hour, 1 minute, and
  49. a maximum value, as well as, a need for classes of operators since
  50. aggregation is different for counters vs.  an interface status variable.
  51. Agreement was reached to rewrite the section to make it more clear.
  52.  
  53. Would the addition of comments within the data files be useful?  Yes,
  54. add comments, something like:
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.      FS :== ``,'' | <LF> | <LF> # text <LF>
  63.  
  64.  
  65. Additional questions were posed by Dave S. (BNL).
  66.  
  67.  
  68.    o What is the use of the networkname field?  Ross noted that network
  69.      names were unique.  Evan noted that the sharing of data among
  70.      networks would be facilitated such that data wouldn't possibly
  71.      become confused.  Consensus was reached that the networkname field
  72.      was useful :-).
  73.  
  74.    o Question about the routername.  This brought up a bigger discussion
  75.      about how addresses are bound to each interface on a router.
  76.      Usually the name of a router is tied to the interface most commonly
  77.      used to access it.  The name must be unique.  Discussion digressed
  78.      to involve yellow post-its and neon lights to name routers.  Matt
  79.      mentioned limitations of the DNS to name routers usefully.  No
  80.      action was taken.
  81.  
  82.    o Questions about the linkname prompted discussion on what should be
  83.      in it and what would be mandatory.  The concept of a virtual link
  84.      is needed to represent one or more physical links which can be
  85.      grouped for statistical purposes.  Should the name represent the
  86.      ISO layer 2 or layer 3 name?  Should there be an external name map
  87.      to map the linkname field to a meaningful string?  How should
  88.      information be encoded in the field?  Should there be resource vs.
  89.      time aggregation?  There are several unanswered question which
  90.      could be answered in a later document covering implementation
  91.      details.
  92.  
  93.  
  94. Ed Reeder (IBM) suggested several editorial comments.  All were approved
  95. as suggested.
  96.  
  97. In Section 5.1 there was a question about the difference between the raw
  98. data and the presented data.  Agreement was reached to rewrite
  99. sentence/section to make more clear about the difference between the
  100. two.
  101.  
  102. In a separate discussion, Matt suggested adding a field to show
  103. specifically whether the data had been aggregated, versus having an
  104. implicit indication currently.  Everyone agreed to this change.
  105.  
  106. There was some question about having a minimum value as well.  Lengthy
  107. discussion about the minimum value always being very close to or equal
  108. to 0.  Consensus had been reached at an earlier meeting to drop the
  109. minimum value.
  110.  
  111. James Barr (NIKHEH-H) asked a question about adding a comment.  Since
  112. this had been agreed to previously, no further discussion was held.
  113.  
  114. Peter Fenwick (Univ.  of Auckland) pointed out a syntax error in Section
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122. 6.1.3 in the data field specification where the number of ``[`` and ''
  123. ]'' were unequal.  Everyone agreed the error should be fixed.
  124.  
  125. Pietrak Rafal had extensive comments on the aggregation periods in the
  126. draft.  Comments about the effect of extra weekend days in a month
  127. skewing data for a physical month, as well as, as questions about the
  128. period of time we wanted a peak value for raised.  Everyone agreed that
  129. two hours was too long of a period.  Agreement was reached to leave the
  130. time values as they were in the Internet Draft.
  131.  
  132. Is the draft ready for RFC'ing?
  133.  
  134. Agreement was reached that the draft was getting close and needed the
  135. changes mentioned above.  Once the changes are made, Bernhard will send
  136. a copy for review before forwarding it to the IESG.
  137.  
  138. Future Tool Development
  139.  
  140. Eric Hood, Executive Director of FARNET, made some comments about
  141. network statistics and the availability of financial assistance from
  142. FARNET to help fund some amount of development.  Eric was going to have
  143. the FARNET staff survey networks to see what tools are currently
  144. available and what is under development.  Everyone agreed that there
  145. needed to be reference implementations to flesh bugs out of the draft
  146. (and future drafts) and show the direction of future work.  A Consensus
  147. was reached on the need for a common way to store data and to share
  148. common tools which are freely redistributable (in the public domain).
  149. We are currently unsure of the questions which will need to be asked at
  150. some point about what statistics are important and implementations will
  151. help answer the questions.
  152.  
  153. Eric will do the survey and forward the results to the OPSTAT Working
  154. Group.  Discussions about tools will continue at the Washington, DC
  155. IETF, November 16-20, 1992.
  156.  
  157. Attendees
  158.  
  159. Vikas Aggarwal           aggarwal@nisc.jvnc.net
  160. Tony Bates               tony@ean-relay.ac.uk
  161. Henry Clark              henryc@oar.net
  162. Robert Collet            rcollet@icm1.icp.net
  163. Scott Cossette           sdc@concord.com
  164. Osmund de Souza          osmund.desouza@att.com
  165. Tom Easterday            tom@cic.net
  166. Roger Fajman             raf@cu.nih.gov
  167. Stefan Fassbender        stf@easi.net
  168. Cliff Frost              cliff@cmsa.berkeley.edu
  169. Martyne Hallgren         martyne@mitchell.cit.cornell.edu
  170. Eugene Hastings          hastings@a.psc.edu
  171. Eric Hood                ehood@nwnet.net
  172. John Labbe               labbe@merit.edu
  173. Walter Lazear            lazear@gateway.mitre.org
  174. Hock-Koon Lim            lim@po.cwru.edu
  175. Kim Long                 klong@sura.net
  176. Matt Mathis              mathis@a.psc.edu
  177.  
  178.                                    3
  179. ^L
  180.  
  181.  
  182.  
  183.  
  184. John McKenna             mckenna@ralvm12.vnet.ibm.com
  185. Chris Myers              chris@wugate.wustl.edu
  186. Kraig Owen               tko@merit.edu
  187. Sonya Reimer             sonya@brl.mil
  188. Robert Reschly           reschly@brl.mil
  189. Bernhard Stockman        boss@sunet.se
  190. Ross Veach               rrv@uiuc.edu
  191. Curtis Villamizar        curtis@ans.net
  192. Evan Wetstone            evan@rice.edu
  193. Chris Wheeler            cwheeler@cac.washington.edu
  194. Linda Winkler            lwinkler@anl.gov
  195.  
  196.  
  197.  
  198.                                    4
  199.  
  200.